1. Field of Invention
The present invention relates to software systems such as database systems. More specifically, the invention relates to efficiently evaluating the impact of a software update on a customer system prior to the implementation of the software update.
2. Description of the Related Art
Software providers often improve upon software applications which have been released. In order for customers who have purchased the software applications to benefit from the improvements developed by the software providers, the software providers often provide software updates to the customers. Software updates, which are often known as patches, typically contain code which is intended to be uploaded, e.g., uploaded by a customer, to augment software installed on a customer system. Such software updates generally include either or both code which is suitable for fixing a bug in the software installed on the customer system or code which provides new enhancements or upgrades to the software.
When a customer receives a software update, or receives notification that a software update is available for installation, the customer must schedule downtime during which the customer system on which software is installed is taken offline for purposes of installing the software update. The installation or implementation of the software update generally requires downtime for uptaking the software update and performing various tests on the software to ensure that the software is still functional after the uptaking of the software update. Since it is not known to the customer how the software update will affect his or her system, i.e., since the impact on his or her system is not known before the software update is uptaken, the customer generally schedules downtimes which may be far longer than is actually required. In other words, without knowledge of which files, components, business objects, or features associated with the customer instance of the software will likely be affected by the software update, the customer is forced to schedule a relatively long downtime in an effort to make certain that there will be more than sufficient time to uptake the software update, to restart the system after uptaking the software update, to recompile any files which are affected code after uptaking the software update, and to test the system after the software update is in place.
Any time there is downtime for a customer system, the cost of ownership for the customer system is increased. That is, any time a customer is unable to run his or her software due to the implementation of a software update, the customer may lose both time and money as any processes which utilize the system are halted while the software update is implemented. While scheduling a long downtime for a customer system due is effective to ensure that the installation of a software update is completed, when the actual number of files, components, business objects, or features impacted by the software update is small, the actual needed downtime may be significantly less than the scheduled downtime. By way of example, the amount of time needed for the uptake of a software update which impacts a small number of files and the amount of time needed to test the small number of files that are impacted by the software update may be relatively short compared to the scheduled downtime which is typically arranged to accommodate a scenario in which most files are impacted by a software update and most files need to be retested. As a result, a substantial portion of the scheduled downtime may actually be unnecessary in many cases.
In order to more accurately schedule downtime such that the scheduled downtime may be more likely to be close to the actual required downtime, some customers may attempt to manually estimate the amount of downtime that is likely to be required. Manually estimating a required downtime may involve studying the software update, and matching files in the software update to files of a customer system. In addition, customers may also have to manually speculate what components, business objects, and features would likely be affected by the software update. Any manual process of estimating a required downtime may be both time-consuming and error prone.
Therefore, what is needed is a method and an apparatus which enables an efficient scheduling of downtime to install a software update. That is, what is desired is a method and an apparatus which enables a customer to accurately and efficiently determine how much downtime to schedule for a software update by effectively estimating a potential impact of the software update prior to installing the software update using an automated process.